Module 05 closure
Prepared by Greg Kinney
February 25, 2006
MUDDY ITEM Q&A
Q: The role and function of risk management was understood (at least from the associated reading). The number of steps and procedures used to identify and ultimately record risk was staggering. I didn’t realize so much effort was put into the risk management portion of a project. It read like it was it’s own separate function or role (and I guess it is to a point).
A: It must be understood that the risk management process “steps,” as laid out in PMBOK (see Chapter 4 section on “Organizing for Risk Management”) will seldom be carried out for each and every project. The first part, Risk Management Planning, should be governed by a general risk management policy by the company, which should provide guidance as to how to manage risks for projects and operational activities. In terms of risk identification, this can be relatively informal for small jobs, generating job hazard analyses (JHAs), for instance. For larger jobs, you’ll want to systematically think about what can go wrong (Risk Identification) and then think about the severity (impact) and likelihood (probability) of those things based on judgment and gut feel (Qualitative Risk Analyses). Once you have this, you can arrange the risks on a single matrix, plotting where the risks are in terms of probability and likelihood. The ones you want to manage actively are the ones with the combined impact and likelihood scoring the highest. You need to ignore those that do not pose a credible risk. Those in the middle must be monitored. (A good reference I read some years ago is Proactive Risk Management by Preston Smith and Guy Merritt, available through amazon.com or Barnes & Noble online.)
For big projects, a Quantitative Risk Analysis may be warranted. This applies a much more rigorous and logically defensible approach to establishing impacts and likelihoods through engineering assessments such as simulation and other analytic tools. The answers generally will be better than provided by Qualitative Risk Assessments but one thing is for sure – the process is much more expensive, requiring lots of effort and probably some expensive consultants to help out.
The Risk Response Planning step and Risk Monitoring and Control should ideally be governed by general policies. But sizable projects may warrant customization of risk response and monitoring plans. PMBOK discusses this in detail.
Note that it is simply impossible to actively manage all conceivable risks; moreover, it is not even possible to imagine all the risks your project may be subject to. But a robust Risk Management plan makes it likely that, should the unforeseen risk take precedent over other risks, you will have the tools in place to manage it properly.
Q: The discussion on the FMEA was pretty slim to say the least. I understood the basics of the Failure Mode and Effect Analysis but there wasn’t a good example of this tool. Besides that, what if you leave out a potential suspect. In other words, what if you don’t identify the way a project did fail. Can you go back and capture that data for future projects? Does the Risk Management office critique this information at the end of every project?
A: The FMEA approach was designed for the process industries to be a thorough vetting of potential ways that a failure can occur, mapping potential failures and the barriers in place to prevent them. People have put together approaches that appear reasonably good for mapping out systematically how systems can fail in a plant process context. Even there you may overlook something, but you are far better off having gone through that process than you would have been had you not.
For more information on FMEA, the classic in the “quant” field is Guidelines for Chemical Process Quantitative Risk Analysis from the Center for Chemical Process Safety of the American Institute of Chemical Engineers. I have to warn you, though, it’s not cheap at $189 per copy. As noted, FMEA is generally built around process issues, where you can physically map the safeguards against failures that are built into process plant designs; you then look at the likelihoods of individual component failures and you can look at how they may roll up into cascading failures. FMEA generally is built on a combination of hard data – lots of data regarding failure probabilities of individual components may be used – and judgmental probabilities where numbers don’t exist.
This could be adapted to project failure analysis, but it’s a little bit of a stretch. What the text describes on page 206 is not really FMEA as I have known it from industry. That doesn’t mean it’s no good, it just means it’s a different animal. Really it’s a qualitative (judgment based) risk prioritization scheme that adds on a detection term to the severity and likelihood to come up with a “risk priority number” or RPN. It is a little like the methodology used in “Reliability Based Maintenance” assessments used to prioritize maintenance work. We could gin up examples, but the key thing to know is that these RPNs are used relative to one another to direct attention in risk management.
As for capturing overlooked risks that came true – that should be rolled into future risk management in a systematic way, by updating the initial analyses after the “lessons learned” or “after action” reports are filed. In my experience, it’s easier said than done, because organizations typically lack the mechanism for integrating lessons systematically unless it’s either easy to do through procedures or it’s spectacular enough to require rethinking the process. It’s especially hard to propagate “lessons learned” information to future projects, because of constant turnover of personnel and because of the (partially correct) presumption that each project is unique. The latter leads to an implicit assumption that our current projects are so unique that no previous lesson can apply.
Q: "The muddiest" was the mixed organizational systems, this organizational form seems strange to me, I don't see how this is implemented in the organization. Is it just a project group in a functionally organized company for a given/short period of time, where people from different branches are formed into a project group?
A: It can happen this way. In many companies, including mine, there is a permanent Projects department within a basically functional organization. In effect, Projects is just another functional department within the overall organization. It is an organization whose function is to guide design and construction of projects, just as Payroll Accounting’s function is to track and execute payroll. In some smaller companies, it might make sense to make Projects a temporary, rather than permanent, part of the organization, but that would make no sense for us.
Even in a company like ours, with its functional projects organization, it still makes sense to “matrix in” resources into a project group especially when specialized help is needed. For example, the very best choice for a Project Engineer or lead electrical engineer might turn out to be the individual currently assigned as a Facility Engineer in a particular location. But the job is too small to warrant reassignment, so you use that person’s talents for the short term, effectively “borrowing” him or her for the project work, and returning him or her to the prior position, which he/she never left.
Q: We talk a lot about what a PM is and the responsibilities of the PM. But, the module only gives a brief (and inadequate) description of who exactly the program manager is. I understand that the program manager is the person that the PM reports to. And I have the feeling that the program manager once was a PM on projects, but how does the program manager’s role change?
A: I have noticed that a number of students have become confused on the issue of programs vs. projects. I think this may be partly due to the fact that the authors neglected to repeat or reinforce their definition of “program” from early in the text. This leads to some confusion, as the text appears to suggest that program managers exist in every organization and that project managers report up to a program manager. Not so. There are two definitions of “program” used operationally. The first is a recurrent (annual) project or operational activity with year-after-year longevity. Second is the text definition, an “exceptionally large, long range objective” which spawns projects to fulfill the objective (e.g., the NASA shuttle program). Yes, if there is a program, then the PMs who are supporting projects created for that program will generally report to the program manager. The Program Manager is then a kind of super-project manager; the one that all the PMs report to. He or she is a manager of managers, but probably does have a PM background.
Q: It seems that the text separates the project management office from the project management team in stating that it is the facilitator of projects rather that the doer. Isn’t it impossible to separate the two entities in organizations that have achieved effective project management maturity?
A: Going back to Section 2.1, we read the following: “The project management ‘maturity’ of an organization is assessed as being at one of five levels: ad-hoc (disorganized, accidental successes and failures); abbreviated (some processes exist, inconsistent management, unpredictable results); organized (standardized processes, more predictable results); managed (controlled and measured processes, results more in line with plans); and adaptive (continuous improvement in processes, success is normal, performance keeps improving).” The more mature an organization becomes, the more useful a PMO will be in assuring that the maturity level is maintained and increased. The PMO provides a concrete and systematic way toward improvement. So, it is possible to separate these two entities, and in fact, it’s desirable to have them separate (with the PMO providing guidance and direction to the PM team).
Q: Organization levels, what are the implications of “it (the project) should be placed in that unit with the greatest interest (p. 219)”. What are the real world effects of “placing” a project in, for example, the engineering department? As it is now, it is just a tree structure on a piece of paper. Especially if one consider the different types of matrix organizations.
A: If you place a project responsibility in the unit with the greatest interest in its success, then you will maximize the chances of the project getting off the ground. There is no surer way of killing a job than by assigning it to a group having no interest in it. On the other hand, there is a real negative side, which is just a reflection of the overall problem with functional organizations. They tend to be silos – functional groups don’t tend to interact well with other functional groups. They act in their narrow self interest and they often cannot grasp what another group is really up against. I have observed Operations, Engineering and Projects organizations that have historically been suspicious of one another and cast blame on each other when things go wrong. What I’m saying is that you may assign a project to Engineering, but when it goes there, others may become more suspicious in the end.
MOST USEFUL AND MEANINGFUL ITEMS (note: some listed items did not show complete thought or adequate elaboration – points were deducted in grading for quality)